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Simple Summary 


Creates a new transaction type which executes a package of one or more 
transactions, while passing status information to subsequent transactions. 


Abstract 


Introduce a new transaction type which includes a list of transactions that must be 
executed serially by clients. Execution information (e.g. success, gas_used, etc.) will be 
propagated forward to the next transaction. 
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Motivation 


Onboarding new users to Ethereum has been notoriously difficult due to the need for 
new users to acquire enough ether to pay for their transactions. This hurdle has seen 
a significant allocation of resources over the years to solve. Today, that solution is 
meta-transactions. This is, unfortunately, a brittle solution that requires signatures to 
be recovered within a smart contract to authenticate the message. This EIP aims to 
provide a flexible framework for relayers to “sponsor” many transactions at once, 
trustlessly. 


Meta-transactions often use relay contracts to maintain nonces and allow users to 
pay for gas using alternative assets. They have historically been designed to catch 
reversions in their inner transactions by only passing a portion of the available gas to 
the subcall. This allows them to be certain the outer call will have enough gas to 
complete any required account, like processing a gas payment. This type of subcall 
has been considered bad practice for a long time, but in the case of where you don't 
trust the subcalls, it is the only available solution. 


Transaction packages are an alternative that allow multiple transactions to be 
bundled into one package and executed atomically, similarly to how relay contracts 
operate. Transactions are able to pass their result to subsequent transactions. This 
allows for conditional workflows based on the outcome of previous transactions. 
Although this functionality is already possible as described above, workflows using 
transaction packages are more robust, because they are protected from future 
changes to the gas schedule. 


An important byproduct of this EIP is that it also facilitates bundling transactions for 
single users. 


Specification 


Introduce a new EIP-2718 transaction type where id = 2. 


Structure 


struct TransactionPackage { 
chain_id: u256, 
children: [ChildPackage], 
nonce: u64, 
gas_price: u256, 


v: u256, 
Ps U256; 
Ss: u256 
} 
Hash 
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keccak256(rlp([2, chain_id, children, nonce, gas_price, v, r, s]) 


Signature Hash 


keccak256(rlp([2, chain_id, children, nonce, gas_price]) 


Receipt 


Each cChildTransaction transaction will generate a ChildReceipt after execution. Each 
of these receipts will be aggregated into a Receipt . 


type Receipt = [ChildReceipt] 


struct ChildReceipt { 
status: u256, 
cumulative_gas_used: u256, 
logs bloom: [u8; 256], 
logs: [u8] 


Child Transaction 


Let ChildPackage be interpreted as follows. 


struct ChildPackage { 
type: u8, 
nonce: u64, 
transactions: [ChildTransaction], 
max_gas_ price: u256, 
v: u256, 
r: u256, 
s: u256 


struct ChildTransaction { 
flags: u8, 
to: Address, 
value: u256, 
data: [u8], 
extra: [u8], 
gas_limit: u256 


Types 


The type field is used to denote whether the child signer wishes to delegate the 
max_gas_price and gas_limit choice to the TransactionPackage signer. 
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type signature hash 
0x00 keccak256(rlp([0, nonce, transactions, max_gas_price]) 
@x@1 keccak256(rlp([1, nonce, transactions _without_gas_limit]) 


Validity 


A TransactionPackage Can be deemed valid or invalid as follows. 


fn is_valid(config: &Config, state: &State, tx: TransactionPackage) bool { 


if ( 
config.chain_id() != tx.chain_id || 
tx.children.len() == © || 
state.nonce(tx.from()) + 1 != tx.nonce 
)f 


return false; 


let cum_limit = tx.children.map(|x| x.gas_limit).sum(); 
if state.balance(tx.from()) < cum_limit * tx.gas_price + intrinsic_gas(tx) { 
return false; 


for child in tx.children { 
if ( 
child.nonce != state.nonce(child.from()) + 1 || 
child.value > state.balance(child.from()) || 
child.max_gas_price < tx.gas_ price 


yt 


return false; 


for tx in child.txs { 
if ( 
tx.flags != @ || 
tx.extra.len() != @ || 
tx.gas_ limit < intrinsic_gas(tx) 
Ps 


return false; 


true 
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Results 


Subsequent ChildTransaction s will be able to receive the result of the previous 
ChildTransaction Via RETURNDATACOPY (0x3E) in first frame of execution, before 
making any subcalls. Each element, except the last, will be o -padded left to 32 bytes. 


struct Result { 
// Status of the previous transaction 
success: bool, 


// Total gas used by the previous transaction 
gas_used: u256, 


// Cumulative gas used by previous transactions 
cum_gas_used: u256, 


// The size of the return value 
return_size: u256, 


// The return value of the previous transaction 
return_value: [u8] 


Intrinsic Cost 


Let the intrinsic cost of the transaction package be defined as follows: 


fn intrinsic_gas(tx: TransactionPackage) u256 { 
let data_gas = tx.children.map(|c| c.txs.map(|t| data_cost(&c.data)).sum()).sum( 
17000 + 8000 * tx.children.len() + data_gas 


Execution 


Transaction packages should be executed as follows: 


. Deduct the cumulative cost from the outer signer’s balance. 

. Load the first child package, and execute the first child transaction. 

. Record all state changes, logs, the receipt, and refund any unused gas. 

. If there are no more child transactions, goto 8. 

. Compute Result for the previously executed transaction. 

. Prepare Result to be available via return opcodes in the next transaction’s 
first frame. 

7. Execute the next transaction, then goto 3. 

8. Load the next child package, then goto 7. 


Nm KR WD 
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Rationale 
Each child has its own signature 


For simplicity, the author has chosen to require each child package to specify its own 
signature, even if the signer is the same as the package signer. This choice is made to 
allow for maximum flexibility, with minimal client changes. This transaction can still 
be used by a single user at the cost of only one additional signature recovery. 


ChildPackage specifies max_gas_price instead of 
gas_price 


Allowing child packages to specify a range of acceptable gas prices is strictly more 
versatile than a static price. It gives relayers more flexibility in terms of building 
transaction bundles, and it makes it possible for relayers to try and achieve the best 
price for the transaction sender. With a fixed price, the relayer may require the user to 
sign multiple different transactions, with varying prices. This can be avoided by 
specifying a max price, and communicating out-of-band how the urgency of the 
transaction (e.g. the relayer should package it with the max price immediately vs. 
slowly increasing the gas price). A future transaction type can be specified with only a 
single signature, if such an optimization is desired. 


ChildPackage is also typed 


The type element serves a modest role in the transaction type, denoting whether the 
transaction signer wishes to delegate control of the gas price and gas limit to the 
outer signer. This is a useful UX improvement when interacting with a trusted relayer, 
as once the user decides to make a transaction the relayer can ensure it is included 
on chain by choosing the best gas price and limit. 


The flags and extra fields aren't used 


These fields are included to better support future changes to the transaction type. 
This would likely be used in conjunction with the flags and type fields. A benefit of 
explicitly defining them is that specialized serialization of RLP can be avoided, 
simplifing clients and downstream infrastructure. The author believe the cost of 2 
bytes per transaction is acceptable for smoother integration of future features. 


Backwards Compatibility 


Contracts which rely on ORIGIN (0x32) == CALLER (0x33) && RETURNDATASIZE (@x3D) == 
əxðð will now always fail in transaction packages, unless they are the first executed 
transaction. It's unknown if any contracts conduct this check. 


Test Cases 
TBD 
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Implementation 
TBD 


Security Considerations 
Managing packages efficiently in the mempool 


The introduction of a new transaction type brings along new concerns regarding the 
mempool. Done naively, it could turn into a DDoS vector for clients. This EIP has been 
written to reduce as much validation complexity as possible. 


An existing invariant in the mempool that is desirable for new transactions to 
maintain, is that transactions can be validated in constant time. This is also possible 
for packaged transactions. There is an inherent 10Mb limit for RLPx frames, so that 
would be the upper bound on transactions that could be included in a package. On 
the other hand, clients can also just configure their own bound locally (e.g. packages 
must be less than 1Mb). Validity can then be determined by using the function above. 


Once a package has been validated, it must continuously be monitored for nonce 
invalidations within its package. One potential way to achieve this efficiently is to 
modify the mempool to operate on thin pointers to the underlying transaction. This 
will allow packages to ingest as many “single” transactions, simplifying the facilities 
for monitoring changes. These “parts” of the package can maintain a pointer to a 
structure with pointers to all the parts of the package. This way, as soon as one part 
becomes invalid, it can request the parent to invalidate all outstanding parts of the 
package. 
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